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TUTORIAL 


INTEROPERABILITY  IN 
DOD  ACQUISITION  PROGRAMS 
THROUGH 

ENTERPRISE  "ARCHITEQING" 


Mary  Undo  Polydys 

Joint  Vision  (JV)  2020  guides  the  continuing  transformation  of  America’s  Armed 
Forces  toward  information  superiority  in  the  ongoing  “information  revoiution.” 
JV  2020  states  that  information  superiority  “is  a  key  enabier  to  this  trans¬ 
formation,’’ and  that  interoperabiiityfaciiitates  information  superiority. This  articie 
discusses  the  roie  of  enterprise  architecture  in  the  acquisition  of  interoperabie 
systems  in  the  Department  of  Defense. 


Joint  Vision  (JV)  2020  guides  the  con¬ 
tinuing  transformation  of  America’s 
armed  forces  toward  a  goal  of  in¬ 
formation  superiority.*  JV 2020  states  that 
“the  ongoing  ‘information  revolution’  is 
creating  not  only  a  quantitative,  hut  quali¬ 
tative  change  in  the  information  environ¬ 
ment  that  hy  2020  will  result  in  profound 
changes  in  the  conduct  of  military  opera¬ 
tions”  (Chairman  Joint  Chiefs  of  Staff 
[CJCS],  2000,  June,  p.  8).  Because  infor¬ 
mation,  information  processing,  and  com¬ 
munications  networks  are  at  the  core  of 


every  military  operation,  JV  2020  ac¬ 
knowledges  the  major  role  of  informa¬ 
tion  and  information  technology  in 
achieving  information  superiority. 

The  JV  2020  discussion  on  informa¬ 
tion  superiority  is  followed  hy  a  discus¬ 
sion  on  interoperability^  and  its  role  in 
achieving  information  superiority.  JV 
2020  states  that  “Interoperability  is  a 
mandate  for  the  joint  force  of  2020  — 
especially  in  terms  of  communications, 
common  logistics,  and  information 
sharing”  (CJCS,  2000,  p.  15).  With  re- 


DISCLAIMER 

Any  opinions  expressed  in  this  article  are  those  of  the  author  and  do  not  reflect  the  official 
policy  or  position  of  the  National  Defense  University,  Defense  Acquisition  University,  the 
Department  of  Defense,  or  the  United  States  Government. 
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spect  to  interoperability,  JV  2020  states 
that  “Information  systems  and  equip¬ 
ment  that  enable  a  common  relevant 
operational  picture  must  work  from 
shared  networks  that  can  be  accessed 
by  any  appropriately  cleared  partici¬ 
pant”  (CJCS,  2000,  p.  15).  JV  2020  fur¬ 
ther  acknowledges  that  interoperability 
goes  beyond  technical  interoperability 

and  includes  a 
focus  on  pro¬ 
cedures  or  or- 
ganization. 
“Although 
technical 
interoper- 
ability  is  es¬ 
sential,  it  is  not 
sufficient  to 
ensure  effec¬ 
tive  operations.  There  must  be  a  suit¬ 
able  focus  on  procedural  and  organiza¬ 
tional  elements,  and  all  decision-mak¬ 
ers  at  all  levels  must  understand  each 
other’s  capabilities  and  constraints” 
(CJCS,  2000,  p.l5). 

This  article  addresses  the  role  of  en¬ 
terprise  architecture  in  documenting 
interoperability  requirements  and  to 
some  extent,  procedural  and  organiza¬ 
tional  interoperability  requirements  in  the 
Department  of  Defense  (DoD)  system 
acquisition.  More  specifically,  this  article 
addresses  the  use  of  enterprise 
architecture  products^  in  creating 
interoperability  key  performance  param¬ 
eters'*  (KPPs)  for  Capstone  and  Opera¬ 
tional  Requirements  Documents  (CRDs 
and  ORDs)  and  documenting  interoper¬ 
ability  and  supportability  requirements 
for  the  Command,  Control,  Communi¬ 
cation,  Computers,  and  Intelligence 
(C4I)  Support  Plan.  However,  before 


these  subjects  are  covered,  it  is  useful 
to  briefly  review  the  concepts  of  en¬ 
terprise  architecture  as  mandated  in  law 
and  regulation. 

"Architecting"  as  a  Mandate 

The  requirement  for  enterprise  ar¬ 
chitecture  is  mandated  in  the  Clinger- 
Cohen  Act  of  1996.  This  act  requires 
that  all  Federal  Government  chief  in¬ 
formation  officers  “develop  maintain, 
and  facilitate  the  implementation  of  a 
sound  and  integrated  information  tech¬ 
nology  architecture”  [40  U.S.C.  §1425 
‘]I(b)  (2)].  The  act  further  defines  infor¬ 
mation  technology  architecture  (often 
called  enterprise  architecture)  as  “an 
integrated  framework  for  evolving  or 
maintaining  existing  information  tech¬ 
nology  and  acquiring  [emphasis 
added]  new  information  technology  to 
achieve  the  agency’s  strategic  goals 
and  information  resources  manage¬ 
ment  goals”  [40  U.S.C.  §1425  Kd)]. 

The  Clinger  Cohen  Act  architecture 
mandates  are  implemented  in  Office 
of  Management  and  Budget  (0MB) 
Circular  A- 130  (2000).  0MB  Circular 
A- 130  (2000)  states  that  an  enterprise 
architecture  must  include  a  description 
of  the  business  or  operational  pro¬ 
cesses,  information  flows  and  relation¬ 
ships,  data  descriptions  and  relation¬ 
ships,  applications,  and  technology  in¬ 
frastructure.  The  enterprise  architecture 
must  also  include  a  technical  reference 
model  and  standards  profile  (includ¬ 
ing  a  security  standards  profile).  This 
circular  requires  that  federal  agencies 
establish  an  architecture  framework 
that  would  provide  specific  agency 


"JV2020  further 
acknowledges  that 
interoperability 
gees  beyond  techni- 
cai  intereperabiiity 
and  inciudes  a  focus 
on  procedures  or 
organization." 
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direction  on  developing  enterprise  ar¬ 
chitectures. 

The  DoD  developed  their  architec¬ 
ture  framework  in  1997,  titled  Com¬ 
mand,  Control,  Communication,  Intel¬ 
ligence,  Surveillance,  and  Reconnais¬ 
sance  (C4ISR)  Architecture  Framework 
(future  editions  to  he  renamed  DoD 
Architecture  Framework;  see  DoD, 
2001h,  ‘1IC6.3.2).  This  framework  or¬ 
ganizes  DoD’s  enterprise  architecture 
into  three  views  (e.g.,  operational  ar¬ 
chitecture  view,  systems  architecture 
view,  and  technical  architecture  view) 
and  provides  a  set  of  rules  for  DoD  or¬ 
ganizations  to  follow  in  creating  their 
architecture  descriptions. 

The  purpose  of  the  operational  archi¬ 
tecture  view  is  to  provide  a  clear  opera¬ 
tional  picture  for  decision-making.  At 
the  heart  of  this  view  are  the  operational 
concept,  operational  processes,  and 
information  exchanges.  This  view  con¬ 
tains  graphical  and  textual  descriptions 
(architecture  products)  defining  the 
tasks/activities/processes,  operational 
nodes^  or  elements,  and  information 
exchange  requirements  (lERs)®  between 
nodes.  The  process  and  lERs  descrip¬ 
tions  may  he  supplemented  hy  business 
rules,  data  descriptions,  and  sequenc¬ 
ing  and  timing  descriptions. 

The  purpose  of  the  system  architec¬ 
ture  view  is  to  provide  a  clear  picture 
of  the  systems  and  communications  that 
support  the  operational  concept.  At  the 
heart  of  this  view  are  the  descriptions 
of  system  interfaces  and  communica¬ 
tions  needs  and  capabilities.  This  view 
contains  graphical  and  textual  descrip¬ 
tions  of  the  applications  and  technol¬ 
ogy  infrastructure  to  satisfy  operational 
needs  and  associates  the  physical  re¬ 


sources  to  the  operational  view.  This 
view  illustrates  multiple  systems  infor¬ 
mation  exchanges  via  communication 
links  and  may  describe  the  internal  con¬ 
struction  and  operations  of  particular 
systems.  More  specifically,  this  view 
includes  the 
physical  con¬ 
nections,  loca¬ 
tions,  and  iden¬ 
tification  of  key 
hardware  and 
software;  may 
include  data 
stores,  circuits, 
and  networks; 
and  may  specify 
system  and 
component  per¬ 
formance  parameters. 

The  purpose  of  the  technical  archi¬ 
tecture  view  is  to  provide  the  minimal 
set  of  rules  governing  the  arrangement, 
interaction,  and  interdependence  of  sys¬ 
tem  parts  or  elements.  This  view  con¬ 
sists  of  technical  standards,  conventions, 
rules,  and  criteria  organized  into 
profile(s)  that  govern  system  services, 
interfaces,  and  relationships  for  particu¬ 
lar  systems  views. 

Figure  1  provides  a  cross-walk  be¬ 
tween  the  architecture  components  de¬ 
scribed  in  0MB  Circular  A- 130  and  the 
DoD  architecture  framework.  In  com¬ 
paring  0MB  Circular  A- 130  with  de¬ 
scriptions  of  each  of  the  views,  it  is  evi¬ 
dent  that  DoD  is  consistent  with  the  ar¬ 
chitecture  policy  mandates  of  the  Fed¬ 
eral  Government. 

In  addition  to  the  three  architecture 
views,  the  DoD  architecture  framework 
also  identifies  architecture  products  that 
are  used  to  describe  each  view.  The 


"In  addition  to  the 
three  architecture 
views,  the  DoD 
architecture 
framework  aiso 
identifies  architec¬ 
ture  products  that 
are  used 
to  describe  each 
view." 
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products  that  are  used  in  DoD  system  ac¬ 
quisitions  to  document  interoperability  re¬ 
quirements  and  derive  interoperability 
KPPs  are  defined  and  illustrated  in  this 
article.  They  include  the  following: 

•  OV’-l,  High-Level  Operational  Con¬ 
cept  Graphic. 

•  OV-2,  Operational  Node  Connectivity 
Description. 

•  OV-3.  Operational  Information 
Exchange  Matrix. 

•  OV-6c,  Operational  Event  Trace 
Description. 

•  SV*-!,  System  Interface  Description. 


•  SV-6,  Systems  Information  Ex¬ 
change  Matrix. 

•  TV®- 1,  Technical  Architecture  Pro¬ 
file. 

Using  Architecture  Products 
IN  DoD  System  Acquisitions 


There  are  two  primary  uses  of  archi¬ 
tecture  products  in  DoD  system  acqui¬ 
sitions.  The  first  use  is  in  the  develop¬ 
ment  of  interoperability  KPPs  that  must 
be  included  in  CRDs  and  ORDs.  CJCS 
Instruction  3I70.0IB  (2001)  and  CJCS 
Instruction  6212. OIB  (2000)  provide 
direction  in  deriving  interoperability 
KPPs  from  lERs.  Additionally,  CJCS  In- 
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struction  6212. OIB  (2000)  provides  a 
list  of  DoD  enterprise  architecture  prod¬ 
ucts  that  must  he  included  as  part  of  the 
CRD  (CJCS,  2000,  pp.  C-A-4  through 
C-A-6)  and  ORD  (CJCS,  2000,  pp.  C- 
A-7  through  C-A-10).  The  architecture 
products  that  are  included  with  the  CRD 
and  ORD  provide  supporting  documen¬ 
tation  for  the  interoperability  KPP  and 
document  high-level  interoperability 
requirements. 

A  second  use  is  in  the  evolution  of 
detailed  interoperability  requirements  as 
an  acquisition  proceeds  through  its  life 
cycle.  These  detailed  interoperability  re¬ 
quirements  are  documented  in  the  C4I 
Support  Plan.  CJCS  Instruction 
6212.01B  (2000)  provides  a  list  of  DoD 
enterprise  architecture  products  that 
must  be  included  in  C4I  Support  Plan 
(CJCS,  2000,  pp.  C-B-3  through  C-B- 
9),  and  Appendix  5  of  DoD  5000. 2-R 
(DoD,  2001b)  further  explains  the  use 
of  architecture  products  in  the  C4I  Sup¬ 
port  Plan.  This  plan  “identifies  C4ISR 
needs,  dependencies,  and  interfaces  for 
programs  in  all  acquisition  categories, 
focusing  attention  on  interoperability, 
supportability,  and  sufficiency  con¬ 
cerns”  (DoD,  2001b,  1AP5.1.1).  The 
regulation  further  states  that  the  “level 
of  detail  in  a  C4I  Support  Plan  will  in¬ 
crease  as  an  acquisition  program  pro¬ 
ceeds  from  program  initiation  to  Mile¬ 
stone  C,  and  to  follow-on  blocks  of  an 
evolutionary  acquisition”  (DoD,  2001b, 
1AP5.5.2). 

"Architecting"  Interoperability 
KPPs  AND  Requirements  for  the  CRD 

The  following  is  a  process  for  identi¬ 
fying  interoperability  KPPs  and  require¬ 


ments  for  the  CRD  using  enterprise  ar¬ 
chitecture  products  specified  in  the  DoD 
architecture  framework  (DoD,  1997; 
also  see  CJCS,  2000,  pp.  B-1  through 
B-3). 

CRD  Step  One 

Create  OV-1,  High-Level  Operational 
Concept  Graphic.  The  OV-1  is  a  graphi¬ 
cal  and  text  description  of  the  opera¬ 
tional  concept.  The  graphic  includes 
high-level  organizations,  missions,  geo¬ 
graphic  configuration,  and  connectiv¬ 
ity.  It  is  also  the  most  general  and  flex¬ 
ible  in  format.  Therefore,  the  graphical 
appearance  depends  on  the  scope  and 
intent  of  the  architecture  product.  The 
value  of  OV-1  may  be  characterized  as 
follows: 

•  Provides  context  or  scope  for  a 
family-of-systems  or  system-of-sys- 
tems. 

•  Facilitates  human  communications 
during  the  acquisition  process  by 
orienting  and  focusing  detailed  dis¬ 
cussions. 

•  Facilitates  the  understanding  of  com¬ 
plexity. 

Figures  2  and  3  are  Joint  Meteoro¬ 
logical  and  Oceanographic  (METOC) 
Architecture  examples of  an  OV-1 
graphic  and  its  text  description  for  the 
CRD. 

CRD  Step  Two 

From  the  OV-1,  identify  top-level 
lERs.  The  following  is  a  partial  list  of 
top-level  information  exchanges  for  the 
example: 
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METOC 

Forecast  Centers 
(CONUS) 


Theater-Scale  Products 


Local 
'  Weather 
Observations 


METOC 

Forecast  Centers 
'(CONUS/OCONUS) 


“Regionalized” 

Products 


Area  of  Operations 


Joint 

METOC 

Database 


Local 

Forecast  & 
Decision  Aids 


Figure  2.  CRD  -  High-Level  Operational  Graphic  (OV-1)  for  METOC 


•  METOC  Forecast  Centers  receive 
information  from  weather  satellites. 

•  METOC  Forecast  Centers  receive  in¬ 
formation  from  local  weather  obser¬ 
vation  facilities  at  the  Joint  Task 
Force  (JTF)  Commander’s  location. 

•  Naval  and  air  forces  operating  in  the 


JTF  area  of  operation  receive  weather 
information  from  the  local  weather 
observation  facilities. 

CRD  Step  Three 

Document  top-level  lERs  depicted  in 
OV-1  in  an  Operational  Information 
Exchange  Matrix  (OV-3)  format.  The 
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OV-1 :  Operational  Concept  for  Meteorological  and 
Oceanographic  Support  to  the  Joint  Task  Force 

This  acquisition  faiis  within  the  context  of  the  METOC  operationai  concept.  This  graphic 
represents  the  high-ievei  operational  concept  diagram  for  Joint  METOC.  This  graphic 
conveys  two  major  ideas. 

First,  within  the  Area  of  Operations  (AO),  forces  require  access  to  the  observations  and 
forecasts  of  aii  other  forces  operating  in  the  AO.  In  some  cases  the  exchange  of  METOC 
information  aiso  inciudes  resuits  of  tactical  decision  aids  (TDAs)  or  other  detaiied 
METOC  information  that  drives  the  TDAs  hosted  on  the  computers  of  the  other  Ser¬ 
vices.  Locai  observations  from  the  AO  aiso  need  to  be  communicated  to  the  METOC 
Forecast  Centers  (MFCs)  for  future  anaiysis. 

The  second  major  idea  that  the  graphic  is  designed  to  depict  is  the  concept  that  forces 
in  the  AO  require  access  to  the  theater-scaie  and  space  environment  products  created 
at  two  types  of  MFCs: 

*  Air  Force  and  Navy  woridwide  production  and  ciimatoiogy  faciiities. 

•  Air  Force  and  Navy  theater  component/regionai  METOC  production  faciiities 
that  are  responsibie  for  a  specific  geographic  area. 

Additionaiiy,  the  graphic  depicts  METOC  sateiiites  transmitting  imagery  data  and  at¬ 
mospheric  profiies  to  ail  of  the  conceptual  nodes.  This  shows  that  all  of  the  operational 
[business]  nodes  require  METOC  satellite  information.  Determining  which  nodes  re¬ 
ceive  direct  access  to  METOC  satellite  data  and  which  ones  receive  stored  data  or 
products  derived  from  stored  data,  is  a  design  decision  based  on  CINC  requirements. 
Service-provided  capabilities  (including  METOC  forecast  center  capabilities)  and 
weather  agency  advice  on  the  integration  of  space-based  data  with  other  sources  of 
METOC  data.  The  resulting  structure  is  included  in  the  system  architecture. 

For  the  purpose  of  this  architecture,  it  is  not  important  to  understand  exactly  how  an 
MFC  supports  each  of  its  customers.  However,  an  understanding  of  how  the  MFCs 
support  a  Joint  Task  Force  is  important.  This  level  of  detail  is  provided  in  the  information 
exchange  requirements  (lERs). 


Figure  3.  CRD  -  OV-1  Text  Description  for  METOC 


contents  of  this  matrix  are  the  high-level 
interoperahility  requirements  for  the 
CRD.  Table  1  is  a  METOC  example  of 
OV-3.  For  the  sake  of  brevity,  not  all 
information  exchanges  are  included  in 
the  example. 

Several  points  are  important  in  un¬ 
derstanding  OV-3.  Columns  1  through 


5  are  mandatory  and  6  through  8  are 
optional.  Optional  columns  are  sug¬ 
gested  in  the  DoD  architecture  frame¬ 
work  (1997,  pp.  4-19  through  4-22). 
Column  1  contains  the  tasks  listed  in 
the  Universal  Joint  Task  List  (UJTL). 
Column  2  identifies  the  event.  These 
events  should  be  systemically  designed 
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Table  1.  CRD  -  Infermalien  Exchange  Matrix  (OV-3)  for  METOC 


1 

2 

3 

4 

5 

6 

7 

8 

9 

Info 

UJTL 

EVENT 

INFORMATION 

SEND 

REC 

MEDIA 

QUALITY 

QTY 

CRITICAL 

Exch 

NODE 

NODE 

Op2.2 

Collect 

Atmospheric 

CJTF 

Regional 

Text, 

Updates 

200- 

YES 

Collect 

METOC 

Information:  Air, 

(JMO/ 

METOC 

Data 

Every 

300MB 

1 

Ops 

Information 

Cloud,  Visibility, 

JMFU) 

Forecast 

20 

“raw” 

Info 

Precipitation, 

Center 

Minutes 

data 

Lightning, 

Local 

(MFC) 

Unusual  Weather 

Weather 

OP2.2 

Collect 

Oceanographic 

Satellite 

Regional 

Text, 

Updates 

200- 

NO 

Collect 

METOC 

Information:  Ice, 

Sensor 

Data 

Every 

300MB 

Ops 

Information 

Ice  Berg,  Wave, 

20 

“raw” 

2 

Beach 

Minutes 

data 

Bathymetry, 
Water  Column 

using  some  form  of  process  modeling 
technique.  One  such  technique  is  called 
IDEFO,  Functional  Modeling  Fanguage. 
(Discussion  of  process  modeling  tech¬ 
niques  is  out  of  the  scope  of  this  article.) 
Column  3  lists  the  information  that  is 
exchanged,  column  4  identifies  the 
sending  node,  and  column  5  identifies 
the  receiving  node. 

CRD  Step  Four 

Identify  and  label  critical  top-level 
IFRs.“  In  addition,  lERs  that  must  flow 
down  to  specific  ORDs  must  he  clearly 
identified.  lERs  that  are  critical  will  he 
required  at  threshold.  Notice  that  in  col¬ 
umn  9  of  Table  1  METOC,  the  first  lER 
is  identified  as  critical  and  the  second 
is  not.'^ 

CRD  Step  Five 

Derive  an  interoperability  KPP  from 
the  lERs  documented  in  the  OV-3  ma¬ 
trix.  Table  2  includes  a  very  simple 
interoperability  KPP  for  the  critical  lER 


in  the  METOC  example.  The  first  in¬ 
formation  exchange  in  OV-3  must  be 
satisfactorily  accomplished  for  the 
threshold  objective  value  of  100  per¬ 
cent,  and  all  information  exchanges 
must  be  satisfactorily  accomplished  for 
the  objective  value  of  100  percent. 

"Architecting"  Interoperability  KPPs 
AND  Requirements  for  the  ORD 

Although  the  interoperability  require¬ 
ments  in  the  CRD  are  specified  for  an 
FoS  or  SoS,  the  interoperability  require¬ 
ments  for  an  ORD  are  specified  for  the 
proposed  system  that  is  being  acquired. 
The  following  is  a  process  for  identify¬ 
ing  ORD  interoperability  requirements 
using  architecture  products  specified  in 
the  DoD  architecture  framework  (DoD, 
1997;  also  see  CJCS,  2000,  pp  B-3 
through  B-5). 
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Table  2.  CRD  -  Inlereperabilily  KPP  for  METOC 


Interoperability  KPP 

Threshold  (T) 

Objective  (0) 

All  top-level  lERs  will  be 
satisfied  In  the  threshold 
and  objective  values. 

1 00%  of  top-level  lERs 
designated  critical. 

100%  of  top-level  lERs. 

ORD  Step  One  graphic  (OV-l).  if  the  system  identified 

Identify  top-level  external  interfaces  in  the  ORD  falls  within  the  FoS  or  SoS 

using  a  high-level  operational  concept  identified  in  the  CRD,  the  ORD  OV-l 


Figure  4.  ORD  -  High-Level  Operational  Graphic  (OV-1)  for  METOC 
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must  be  derived  from  the  CRD  OV-1. 
Therefore,  in  some  cases  the  ORD  OV- 
1  may  essentially  be  the  same  OV-1  for 
CRD.  Figure  4  illustrates  an  ORD  OV-1 
for  METOC. 

Notice  that  this  OV-1  is  directly  de¬ 
rived  from  the  CRD  OV-1  for  METOC. 
However,  in  the  OV-1  for  the  ORD  the 
notion  of  a  central  repository  of  infor¬ 
mation  is  the  central  requirement  for  the 
ORD.  In  the  graphic  this  central  reposi¬ 
tory  is  identified  as  the  Joint  METOC 
Database  (JMDB).  A  text  description  is 
also  included  with  this  OV-1  similar  to 


the  text  description  for  the  CRD  OV-1. 
However,  in  this  case  the  text  focuses 
on  the  objectives  of  the  particular  ac¬ 
quisition  requirements  identified  in  the 
ORD  (i.e.,  the  information  repository  — 
JMDB).  Eor  the  sake  of  brevity,  the  text 
example  is  not  included. 

ORD  Step  Two 

Identify  legacy,  current,  and  future 
external  systems  interfaces  that  are 
required  to  exchange  information  us¬ 
ing  a  System  Interface  Description  (SV- 
1).  The  SV-1  provides  a  high-level  pic- 


Figure  5.  ORD  -  Systems  Interface  Description  (SV- 1 )  for  METOC 
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ture  of  the  systems  and  their  interfaces 
for  each  node  and  needline. In  addi¬ 
tion,  it  represents  the  communication 
systems  that  provide  a  path  for  the  in¬ 
formation  exchange  between  systems. 
The  value  of  SV-1  is  characterized  as 
follows:  it  links  operations  or  business 
to  the  physical  need  or  existing  capa¬ 
bility. 

Figure  5  is  an  SV-1  example  for 
METOC.  Notice  that  Figure  5  provides 
a  picture  of  legacy,  current,  and  future 
systems.  The  system  being  acquired, 
JMDB  is  found  in  the  lower  right  box 
(node)  labeled  CJTF/JMO/JMFU. This 
can  be  traced  back  to  ORD  OV-1.  Also 
notice  that  the  ORD  OV-1  depicts  the 
JMDB  in  the  CJTF  area  of  operation. 
There  should  also  be  a  text  explanation 
of  this  graphic  to  define  each  system 
and  the  functions  they  perform.  For  the 
sake  of  brevity,  the  text  description  is 
omitted  from  this  article. 

ORD  Step  Three 

Document  top-level  lERs  for  the 
ORD'^  in  the  Operational  Exchange 


Matrix  (OV-3)  format.  These  high-level 
lERs  are  derived  from  the  ORD  OV-1 
and  the  ORD  SV-1. 

The  lERs  from  the  ORD  are  ad¬ 
dressed  first.  For  the  purposes  of  this 
illustration,  the  lERs  for  the  ORD  flow 
down  from  the  CRD.  In  other  words, 
the  lERs  for  the  ORD  are  the  same  as 
the  lERs  for  the  CRD.  However,  reality 
suggests  that  the  top-level  lERs  for  the 
CRD  are  likely  to  be  decomposed  into 
additional  specific  operational  lERs  for 
each  ORD  under  a  CRD. 

The  next  task  is  to  document  the  lERs 
depicted  in  SV-1.  These  lERs  are  sys¬ 
tems  information  exchanges.  These  sys¬ 
tem  lERs  can  be  documented  by  add¬ 
ing  systems  information  columns  to  the 
OV-3.  Table  3  is  the  OV-3  with  systems 
information  included.  In  Table  3,  two 
columns  are  added.  Colunm  4b  is  added 
to  identify  the  system  that  sends  the  in¬ 
formation,  and  column  5b  is  added  to 
identify  the  system  that  receives  the  in¬ 
formation. 


Table  3.  ORD  -  Infermalien  Exchange  Matrix  (OV-3)  for  METOC 


1 

2 

3 

4a 

4b 

5a 

5b 

6 

7 

8 

9 

Info 

UJTL 

EVENT 

INFORMATION 

SEND 

SEND 

REC 

REC 

MEDIA 

QUALITY 

QTY 

CRITI- 

Exch 

NODE 

SYSTEM 

NODE 

SYSTEM 

CAL 

Op2.2 

Collect 

Atmospheric 

CJTF 

Joint 

Regional 

MFC 

Text, 

Updates 

200- 

YES 

Collect 

METOC 

Information:  Air, 

(JMO/ 

METOC 

METOC 

Database 

Data 

Every 

300MB 

1 

Ops 

Information 

Cloud,  Visibility, 

JMFU) 

Database 

Forecast 

20 

“raw” 

Info 

Precipitation, 

Center 

Minutes 

data 

Lightning, 

Local 

(MFC) 

Unusual  Weather 

Weather 

OP2.2 

Collect 

Oceanographic 

Satellite 

Satellite 

Regional 

MFC 

Text, 

Updates 

200- 

NO 

Collect 

METOC 

Information:  Ice, 

Sensor 

Database 

Data 

Every 

300MB 

2 

Ops 

Information 

Ice  Berg,  Wave, 

20 

"raw” 

Info 

Beach 

Minutes 

data 

Bathymetry, 
Water  Column 
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ORD  Step  Four 

Identify  and  label  critical  lERs  at  the 
ORD  level.  If  the  lER  is  critical  at  the 
CRD  level,  it  is  critical  at  the  ORD  level. 
A  critical  lER  at  the  CRD  is  likely  to  be 
decomposed  at  the  ORD  level  into  ad¬ 
ditional  specific  lERs  for  the  particular 
acquisition.  It  does  not  follow  that  all 
the  decomposed  ORD  lERs  will  be  criti¬ 
cal. 

ORD  Step  Five 

Derive  an  interoperability  KPP  for  the 
ORD  from  the  ORD  Information  Ex¬ 
change  Matrix  (OV-3).  In  the  example, 
the  interoperability  KPP  is  the  same  as 
the  CRD  interoperability  KPP. 

"Architecting"  C4I  Support  Plan 
Interoperability  Requirements 

DoD  5000. 2-R  requires  a  C4I  Sup¬ 
port  Plan  “for  programs  in  all  acquisi¬ 
tion  categories  when  they  connect  in 
any  way  to  the  communications  and  in¬ 
formation  infrastructure.  This  includes 
IT  systems,'®  National  Security  Systems 
(NSS),'’  and  all  infrastructure  programs” 
(2001b,  ‘JIC6.4.2).  The  regulation  re¬ 
quires  that  the  plan  be  kept  current 
throughout  the  program’s  acquisition 
process. 

The  mandatory  procedures  and  for¬ 
mats  for  the  plan  are  found  in  Appendix 
5  of  DoD  5000.2-R  (2001b).  The  pro¬ 
cedures  require  the  use  of  enterprise 
architecture  products  to  describe  infor¬ 
mation  technology  interoperability  re¬ 
quirements.  Specifically,  the  plan  must 
include  the  following: 


•  OV-1,  High-Eevel  Operational 
Concept  Graphic. 

•  OV-2,  Operational  Node  Connectiv¬ 
ity  Description. 

•  OV-3,  Operational  Information  Ex¬ 
change  Matrix. 

•  OV-6c,  Operational  Event  Trace  De¬ 
scription. 

•  SV-1,  System  Interface  Description. 

•  SV-6,  Systems  Information  Ex¬ 
change  Matrix. 

•  TV-1,  Technical  Architecture  Profile. 

The  OV-1,  OV-3,  and  SV-1  may  ini¬ 
tially  be  the  same  as  those  included  as 
part  of  the  ORD.  However,  as  the  ac¬ 
quisition  progresses,  those  architecture 
products  should  be  revised  to  contain 
progressively  more  detailed  and  specific 
descriptions  of  information  require¬ 
ments  and  information  technology  re¬ 
quirements.  The  following  are  the  steps 
in  creating  the  additional  architecture 
products  needed  for  the  C4I  Support 
Plan. 

C4I  Support  Plan  Step  One 

Create  the  Operational  Node  Con¬ 
nectivity  Description,  OV-2.  The  OV-2 
is  derived  from  OV-1  and  is  a  represen¬ 
tation  of  operational  nodes  and  ele¬ 
ments  performing  activities,  represents 
needlines  between  operational  nodes, 
and  identifies  the  characteristics  of  in¬ 
formation  exchanged  between  nodes 
and  elements.  Although  this  enterprise 
architecture  product  is  not  required  by 
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ACTIVITIES  PERFORMED  AT  THE  NODES 
A31 :  Take  Atmospheric  Observations 
A311:  Take  Surface  Observations 
A312:  Take  Upper  Air  Observations 


Geostationary  Imagery 

•  Updates  every  20  min-1 
hr 

•  200-300  MB 

Polar  Orbiter  Imagery 

•  Updates  every  2-12  hrs 


Upper  Air 
Observations 

•  Every  12  hours 

•  1  KB  each 


/'’^Weather'^ 

Radar 


=  Limited  Capability  Currently 
'  =  Node  Performing  Activity 


Figure  6.  C4I  Support  Plan  - 

Operational  Node  Connectivity  Description  (OV-2)  for  METOC 


the  CRD  or  ORD,  documenting  the 
nodes  and  needlines  before  document¬ 
ing  the  lERs  (OV-3,  Operational  Infor¬ 
mation  Exchange  Matrix)  makes  it 
easier  to  identify  the  lERs  that  are  used 
to  derive  interoperahility  KPPs.  The 
value  of  OV-2  is  characterized  as 
follows: 

•  Helps  in  understanding  complex  in¬ 
formation  flows  hy  providing  a  high- 
level  picture  of  those  flows. 

•  Useful  in  making  the  link  between 
business/operations  and  systems. 


Eigure  6  is  the  METOC  OV-2.  A  text 
description  should  also  be  included  with 
each  graphic  as  an  aid  in  understand¬ 
ing  the  contents  (not  included  here  for 
brevity).  Notice  that  for  this  particular 
OV-2,  there  are  several  activities  that  are 
performed  by  the  “node  performing 
activities.” 

The  business  or  operational  activities 
performed  by  those  nodes  include  the 
taking  of  atmospheric  observations, 
which  includes  taking  both  surface  and 
upper  air  observations.  The  graphic  also 
illustrates  where  adequate  and  limited 
capabilities  exist,  suggesting  a  need  for 
improvement  in  the  movement  of  in- 
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formation  between  the  nodes  (a  needed 
interoperability  improvement).  Also  in¬ 
cluded  in  this  graphic  are  boxes  that 
contain  high-level  descriptions  of  infor¬ 
mation  that  is  needed  between  nodes. 
One  such  example  is  the  description  of 
information  relative  to  surface  observa¬ 
tions.  Surface  observations  are  taken 
hourly  and  involve  the  use  of  0.1  KB 
of  data  space. 

C4I  Support  Pian  Step  Two 

Create  the  Operational  Event/Trace 
Description,  OV-6c.  The  OV-6c  is  de¬ 
rived  from  the  OV-2  and  the  OV-3.  To 
ensure  events  are  sequenced  correctly, 
a  process  model  (e.g.,  OV-5,  Activity 


Model)  is  helpful.  The  value  of  OV-6c 
is  characterized  as  follows: 

•  Allows  the  tracing  and  timing  of  ac¬ 
tions  in  a  scenario  or  critical  se¬ 
quence  of  events. 

•  Can  be  used  to  describe  dynamic 
behavior  of  processes. 

Figure  7  illustrates  the  METOC  OV- 
6c.  In  Figure  7  the  timing  is  shown  on 
the  left,  the  operational  nodes  are  at  the 
top,  and  the  events  are  shown  by  ar¬ 
rows  between  nodes.  The  nodes  and  tim¬ 
ing  can  be  traced  back  to  the  OV-2  and 
the  OV-3. 


0100  hr 


0100  hr 


0120  hr 


0120  hr 


Collect  Atmospheric 
Information 


Collect  Atmospheric 
Information 


Collect  Oceanographic 
Information 


Collect  Oceanographic 
Information 


Figure  7.  C4I  Support  Plan  - 
Operational  Even/Trace  Description  (OV-6C)  for  METOC 
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Table  4.  C4I  Support  Plan  - 
Technical  Architecture  Prefiie  (TV-1)  for  METOC 


Application 

Ciass 

Command 
and  Control 

Combat  Support 

GCCS 

METOC 

Application 

METOC 

Analysis 

Application 

Joint 

METOC 

Database 

Alphanumerics 

WMO  A/N  Codes 
Bulletin 

WMO  No.  306, 
Volume  1.1 ,  Part  A 

WMO  A/N  Codes 
Bulletin, 

WMO  No.  306, 
Volume  1.1 ,  Part  A 

WMO  A/N  Codes 
Bulletin, 

WMO  No.  306, 
Volume  1.1 ,  Part  A 

Coded 

Observations 

BUFR,  WMONo. 

306,  Volume  1. 2, 
Parts  B  &  C;  OTH-T 
Gold  WEX 

BUFR,  WMONo. 
306,  Volume  1.2, 
Parts  B  &  C 

BUFR,  WMONo. 
306,  Volume  1.2, 
Parts  B  &  C 

METSAT 

Imagery/Radar 

NITF-V2.0, 

MIL-STD-2500A 

NITF-V2.0, 

MIL-STD-2500A 

NITF-V2.0, 

MIL-STD-2500A 

Other  Imagery 
and 

Graphics 

GIF,  JPEG,  MPEG, 
FIPS  Pub  128-1 
CGM 

GIF,  JPEG,  MPEG, 
FIPS  Pub  128-1 
CGM 

GIF,  JPEG,  MPEG, 
FIPS  Pub  128-1 
CGM 

C4I  Support  Plan  Step  Three 

Create  the  System  Information  Ex¬ 
change  Matrix,  SV-6.  The  SV-6  is,  in 
essence,  documented  when  systems 
characteristic  are  added  to  the  OV-3  (see 
previous  paragraphs  regarding  the  cre¬ 
ation  of  the  ORD  OV-3). 

C4I  Support  Plan  Step  Four 

Create  the  Technical  Architect  Pro¬ 
file,  TV-1.  The  TV-1  lists  the  technical 
standards  chosen  from  the  Joint  Tech¬ 
nical  Architecture  (JTA)  that  apply  to 
the  system  described  in  the  ORD.  The 
value  of  TV-1  is  characterized  as  fol¬ 
lows: 

•  References  how  the  standards  need 

to  he,  or  have  been,  implemented. 


•  Includes  a  discussion  of  relevant 

interoperability  considerations. 

Table  4  illustrates  a  portion  of  TV-1 
for  METOC.  The  standards  in  Table  4 
were  chosen  from  the  standards  listed 
in  the  JTA  at  the  time  that  this  example 
was  documented.  Eigure  8  provides  an 
example  of  the  text  explanation  that 
may  accompany  the  TV-1  matrix  of 
standards. 

Future  Research  Opportunities 


DoD  has  taken  the  first  steps  in  linking 
enterprise  architecture  to  investment  plan¬ 
ning,  acquisition,  and  interoperability.  The 
illustrated  interoperability  KPPs  are  very 
high-level,  overarching  performance 
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•  Note  1:  Section  2.4.1. 2  of  the  Joint  Technicai  Architecture,  v  2.0  states  that  the 
minimum  ievei  of  COE  compiiance  is  Levei  5.  An  Assistant  Secretary  of  Defense  for 
C3I  letter  dated  23  May  1997,  Subject:  Implementation  of  Defense  Information 
Infrastructure  Common  Operating  Environment  Compliance  states,  “All  UNIX-based 
legacy  C4I  systems,  other  than  mainframe  base  systems,  shall  be  Level  5  Dll  COE 
compliant.  All  new  C4I  emerging  systems  and  upgrades  shall  be  level  6  Dll  COE 
compliant  with  the  goal  of  achieving  level  7.” 

*  Note  2:  The  requirement  that  the  Service’s  METOC  Analysis  applications  use  the 
common  mapping  services  of  the  Dll  COE  implies  that  the  JMTK  will  evolve  to 
support  the  display  and  analysis  tasks  required  by  the  Services.  Service  METOC 
Analyst  applications  will  most  likely  migrate  to  the  common  mapping  services  of 
the  Dll  COE  in  concert  with  the  tactical  systems  that  they  support. 

*  Note  3:  The  ultimate  objective  among  all  METOC  applications  is  to  use  common 
physical  schemas  whenever  it  makes  sense.  A  number  of  factors  will  influence  the 
extent  to  which  this  can  be  accomplished,  including  the  nature  of  the  application 
and  the  location  of  the  data  fill.  The  existing  data  management  services  in  the  COE 
may  be  appropriate  for  certain  data  functions  and  not  others. 

•  Note  4:  In  GCCS  and  in  the  Navy,  the  OTH-T  Gold  message  specification  provides 
a  major  link  to  tactical  systems.  While  the  Joint  METOC  Segment  (JMS)  does  not 
require  OTH-T  Gold  formatted  data  as  input  (i.e.,  it  is  capable  of  decoding  GRIB, 
BUFR,  WMO  A/N,  VPF,  etc.  directly),  there  are  operational  requirements  (e.g.,  passing 
of  METOC  products  to  communications-constrained  environments)  in  which  OTH- 
T  Gold  messages  are  the  only  viable  alternative.  In  the  Army,  the  USMTF  message 
specification  (for  alphanumerics)  and  MCS  SITMAP-compatible  formats  (for  vector 
products)  fulfill  a  similar  link  between  METOC  analyst  and  Army  tactical  systems.  In 
the  Air  Force,  Appendix  30  formats  provide  the  link  between  METOC  analyst  and 
USAF  tactical  systems.  It  is  possible  that  in  the  future,  the  Joint  VMF  may  replace 
the  tactical  message  formats  currently  used  by  both  GCCS  and  the  Services. 

Figure  8.  C4I  Support  Plan  -  Text  Explanation  of  TV- 1  for  METOC 


parameters.  As  such,  the  performance 
parameters  will  he  difficult,  if  not  im¬ 
possible,  to  measure.  Therefore, 
interoperability  KPPs  need  to  be  speci¬ 
fied  at  a  level  where  interoperability  can 
truly  be  measured.  To  that  end,  there  is 
an  opportunity  for  research  in  develop¬ 
ing  a  generic  process  for  identifying  spe¬ 
cific  measurement  criteria  associated 
with  interoperability  KPPs.  This  generic 
process  could  be  derived  from  the  work 
done  in  measuring  Levels  of  Informa¬ 


tion  Systems  Interoperability  (LISI). 
Linking  LISI  criteria  to  the 
interoperability  KPPs  may  provide  an 
organized  structure  for  specifying  more 
detailed  interoperability  measures. 

Conclusions 


Using  enterprise  architecture  prod¬ 
ucts  in  DoD  systems  acquisition  docu¬ 
mentation  helps  to  clarify  not  only  the 
operational  and  system  requirements. 
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but  also  facilitates  the  development  of 
interoperability  KPPs  in  support  of  JV 
2020.  In  addition,  illustrating  a  specific 
system  from  a  larger  enterprise  perspec¬ 
tive  (e.g.,  FoS  or  SoS)  enables  DoD  to 
determine  how  well  the  investment  sup¬ 
ports  the  overall  mission.  Lastly,  the 
continuous  refinement  of  the  architec¬ 
ture  products  into  more  detailed  and 
specific,  time-phased  descriptions 
throughout  the  acquisition  process 
should  help  ensure  that  the  investment 
continues  to  support  the  overall  mission 
related  to  the  applicable  FoS  or  SoS. 
Even  though  benefits  are  evident,  there 
is  a  cost  associated  with  creating,  evolv¬ 
ing,  and  maintaining  the  architecture 
products  in  support  of  the  acquisition. 

It  should  be  evident  that  skilled  per¬ 
sonnel  are  needed  to  document  and 
update  enterprise  architecture  descrip¬ 
tions.  In  addition,  it  should  be  clear  that 
the  acquisition  program  organization  is 
likely  to  end  up  with  the  task  of  updat¬ 
ing  the  architecture  products,  especially 
during  the  systems  engineering  process. 
Therefore,  program  managers  need  to 
hire  skilled  personnel  and  ensure  that 
adequate  time  is  budgeted  for  the 
“architecting”  mission  of  the  program. 


Even  though  JV  2020  states  that 
interoperability  includes  more  than 
technical  interoperability,  the  use  of  ar¬ 
chitecture  products  as  identified  in  the 
DoD  acquisition  regulation  focuses  pri¬ 
marily  on  technical  or  systems 
interoperability.  This  is  evidenced  by 
CJCS  Instruction  statements:  “top-level 
lERs  are  defined  as  information  ex¬ 
changes  between  systems”  (6212. OIB; 

2000,  p.  B-1)  and  “Even  though  there 
are  many  facets  of  interoperability... that 
need  to  be  identified  in  the  ORD,  the 
focus  for  the  interoperability  ORD  KPP 
will  be  the  information  exchange  and 
interoperability  level  for  the  ORD  sys¬ 
tem  information  needs”  (3170.  OIB; 

2001,  p.  E-6).  Even  though  systems  suc¬ 
cessfully  share  information,  interoper¬ 
ability  is  not  guaranteed. 

To  that  end,  investment  and  acquisi¬ 
tion  managers  need  to  clearly  under¬ 
stand  and  document  the  operational  or 
business  aspects  of  interoperability  us¬ 
ing  a  structured  method  similar  to  the 
method  described  in  this  article  for  cre¬ 
ating  systems  interoperability  KPPs. 
Only  then  can  interoperability  be 
achieved.  That  said,  most  efforts  con¬ 
tinue  to  focus  primarily  on  technical  or 
systems  interoperability. 
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Endnotes 


1.  Information  superiority:  the  capa¬ 
bility  to  collect,  process,  and  dis¬ 
seminate  and  uninterrupted  flow  of 
information  while  exploiting  or  de¬ 
nying  an  adversary’s  ability  to  do 
the  same  (JPl-02).  Information  su¬ 
periority  is  achieved  in  a  noncom¬ 
bat  situation  or  one  in  which  there 
are  no  clearly  defined  adversaries 
when  friendly  forces  have  the  in¬ 
formation  necessary  to  achieve  op¬ 
erational  objectives  (JPl-02). 

2.  Interoperability:  the  ability  of 
systems,  units,  or  forces  to  provide 
services  from  other  systems,  units, 
or  forces  and  to  use  the  services  so 
exchanged  to  enable  them  to  oper¬ 
ate  effectively  together  (JPl-02). 

3.  Architecture  products  are  the 
graphical,  textual,  and  tabular  out¬ 
put  that  are  created  in  the  course  of 
building  a  given  architecture  de¬ 
scription  and  that  describe  charac¬ 
teristics  relevant  to  the  architecture 
description’s  purpose.  (DoD,  1997, 
p.  4-1). 

4.  Key  performance  parameters  are 
those  capabilities  or  characteristics 
considered  essential  for  successful 
mission  accomplishment  (CJCSI 
6212.01B,  2000,  p.  GL-12). 

5 .  A  node  is  a  representation  of  an  el¬ 
ement  of  architecture  that  produces, 
consumes,  or  processes  data  (DoD, 
1997,  p.  GL-2). 


6.  lERs  characterize  the  information 
exchanges  to  be  performed  by  the 
proposed  Family  of  Systems  (FoS), 
System  of  Systems  (SoS),  or  sys¬ 
tem.  For  CRDs,  top  level  lERs  are 
defined  as  those  information  ex¬ 
changes  that  are  between  systems 
that  make  up  the  FoS  or  SoS,  as  well 
as  those  that  are  external  to  the  FoS 
and  SoS.  lERs  identify  who  ex¬ 
changes  what  information  with 
whom,  why  the  information  is  nec¬ 
essary,  and  how  the  information  ex¬ 
change  must  occur.  Top-level  lERs 
identify  warfighter  information  used 
in  support  of  a  particular  mission- 
related  task  and  exchanged  be¬ 
tween  at  least  two  operational  sys¬ 
tems  supporting  a  joint  or  combined 
mission.  The  quality  (i.e.,  fre¬ 
quency,  timeliness,  security)  and 
quantity  (i.e.,  volume,  speed,  and 
type  of  information  such  as  data, 
voice,  and  video)  are  attributes  of 
the  information  exchange  included 
in  the  information  exchange  re¬ 
quirement  (CJCS,  2000,  p.  GF-10). 

7 .  OV  is  an  indicator  for  an  operational 
architecture  view  product.  In  the 
DoD  architecture  framework  (DoD, 
1997,  p.  4-4)  there  are  seven  op¬ 
erational  architecture  view  prod¬ 
ucts. 

8.  SV  is  an  indicator  for  a  systems 
architecture  view  product.  In  the 
DoD  architecture  framework  (DoD, 
1997,  p.  4-4),  there  are  eleven  sys¬ 
tems  architecture  view  products. 
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9.  TV  is  an  indicator  for  a  technical 
architecture  view  product.  In  the 
DoD  architecture  framework  (DoD, 
1997,  p.  4-4),  there  are  two  techni¬ 
cal  architecture  view  products. 

10.  The  examples  used  throughout  this 
article  are  derived  from  the  Draft 
Joint  Meteorological  and  Oceano¬ 
graphic  (METOC)  Architecture. 
Some  of  the  graphics  and  descrip¬ 
tions  have  been  modified  for  the 
purposes  of  this  article. 

1 1 .  A  critical  lER  is  an  information  ex¬ 
change  that  is  so  significant  that  if 
it  does  not  occur,  the  mission  area 
will  he  adversely  impacted  (CJCS, 
2000,  p.  B-3). 

12.  The  second  lER  is  identified  as  not 
critical  for  the  sake  of  illustration. 

13.  A  needline  is  a  requirement  that  is 
the  logical  expression  of  the  need 
to  transfer  information  among 
nodes.  The  content  of  the  transfer(s) 
is  specified  hy  reference  to  lERs 
(DoD,  1997,  p.  GE-2). 

14.  CJTE  (Commander,  Joint  Task 
Eorce)/JMO  (Joint  Eorce  METOC 
Officer)/JMEU  (Joint  METOC  Eore- 
casting  Unit). 

15.  Eor  ORDs,  top-level  lERs  are  de¬ 
fined  as  those  information  ex¬ 
changes  that  are  external  to  the  sys¬ 
tem  (CJCS,  2000,  p.  CE-10). 


16.  Information  Technology  (IT):  Any 
equipment,  or  interconnected  sys¬ 
tem  or  subsystem  of  equipment,  that 
is  used  in  the  automatic  acquisition, 
storage,  manipulation,  manage¬ 
ment,  movement,  control,  display, 
switching,  interchange,  transmis¬ 
sion,  or  reception  of  data  or  infor¬ 
mation.  The  term  “equipment” 
means  any  equipment  used  by  a 
component  directly  or  used  by  a 
contractor  under  a  contract  with  the 
component  that  requires  the  use  of 
such  equipment,  or  the  use,  to  a  sig¬ 
nificant  extent,  of  such  equipment 
in  the  performance  of  a  service  or 
the  furnishing  of  a  product.  The 
term  “IT”  includes  computers,  an¬ 
cillary  equipment,  software,  firm¬ 
ware,  and  similar  procedures,  ser¬ 
vices  (including  support  services), 
and  related  resources.  The  term  “IT” 
also  includes  national  security  sys¬ 
tems.  It  does  not  include  any  equip¬ 
ment  that  is  acquired  by  a  federal 
contractor  incidental  to  a  federal 
contract  (DoD,  2001c,  1E2.1.5). 

17.  National  Security  System:  Any  tele¬ 
communications  or  information  sys¬ 
tem  operated  by  the  U.S.  Govern¬ 
ment,  the  function,  operation,  or  use 
of  which  involves  intelligence  ac¬ 
tivities;  cryptologic  activities  related 
to  national  security;  command  and 
control  of  military  forces;  equip¬ 
ment  that  is  an  integral  part  of  a 
weapon  or  weapons  system;  or  sub¬ 
ject  to  the  limitation  below,  is  criti¬ 
cal  to  the  direct  fulfillment  of  mili- 
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tary  or  intelligence  missions.  This 
does  not  include  a  system  that  is  to 
he  used  for  routine  administrative 


and  business  applications  (includ¬ 
ing  payroll,  finance,  logistics,  and 
personnel  management  applica¬ 
tions).  This  definition  is  from  the 
Clinger-Cohen  Act  of  1996  (DoD, 
2001c,  1E2.1.14). 
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